[Chapter 35] 35.5 Header Behavior in conf.c
Author: Bryan Costales & Eric Allman
Date: 1999-01-06T21:48:24Z

#

| Chapter 35 Headers |

## 35.5 Header Behavior in conf.c

The sendmail program has a built-in understanding of many header names. How those names are used is determined by a set of flags in the source file conf.c supplied with the source distribution. Site policy determines which flags are applied to which headers, but, in general, conf.c applies them in the way that is best suited for almost all Internet sites. If you desire to redefine the flags for a particular header name, look for the name's declaration in the C language structure definition `HdrInfo` in conf.c. Be sure to read the comments in that file. Changes to header flags represent a permanent site policy change and should not be undertaken lightly. (We illustrate this process after explaining the flags.)

The flags that determine header use are listed in Table 35.2. Note that each flag name is prefixed with an `H_`. Also note that the hexadecimal values are displayed by the `-d31.6` debugging switch (see Section 37.5.114, -d31.6).

Table 35.2: Header Flags in conf.c
Flag | Hex |  | Version | Description
--- | --- | --- | --- | ---
H_EOH | 0x0001 | Section 35.5.1, "H_EOH" | V5 and up | Terminates all headers
H_RCPT | 0x0002 | Section 35.5.2, "H_RCPT" | V5 and up | Contains a recipient address
H_DEFAULT | 0x0004 | Section 35.5.3, "H_DEFAULT" | V5 and up | If already in headers, don't insert
H_RESENT | 0x0008 | Section 35.5.4, "H_RESENT" | V5 and up | Is a `Resent-` header
H_CHECK | 0x0010 | Section 35.5.5, "H_CHECK" | V5 and up | Process `?``flags``?`
H_ACHECK | 0x0020 | Section 35.5.6, "H_ACHECK" | V5 and up | Ditto, but always, not just default
H_FORCE | 0x0040 | Section 35.5.7, "H_FORCE" | V5 and up | Insert header (allows duplicates)
H_TRACE | 0x0080 | Section 35.5.8, "H_TRACE" | V5 and up | Count these to get the hop count
H_FROM | 0x0100 | Section 35.5.9, "H_FROM" | V5 and up | Contains a sender address
H_VALID | 0x0200 | Section 35.5.10, "H_VALID" | V5 and up | Has a validated field value
H_ERRSTO | 0x0800 | Section 35.5.11, "H_ERRSTO" | V8.6 and up | An `errors-to:` header
H_CTE | 0x1000 | Section 35.5.12, "H_CTE" | V8.7 and up | Is "constant transfer encoding"
H_CTYPE | 0x2000 | Section 35.5.13, "H_CTYPE" | V8.7 and up | Is "content type"
H_BCC | 0x4000 | Section 35.5.14, "H_BCC" | V8.7 and up | Strip value from header
H_ENCODABLE | 0x8000 | Section 35.5.15, "H_ENCODABLE" | V8.8 and up | Field can be RFC1522 encoded

Note that there is no flag that always causes a particular header to be removed, nor is there a flag that always causes a particular header to be replaced (although you can trick sendmail with H_ACHECK see Section 35.5.16, "Replacing Headers with H_ACHECK").

### 35.5.1 H_EOH

Headers that are marked with the H_EOH flag cause sendmail to immediately stop all header processing and treat the rest of the header lines as message body. This is useful for separating RFC822-compliant header lines from headers created by a noncompliant network.

### 35.5.2 H_RCPT

Headers that are marked with the H_RCPT flag are assumed to contain valid recipient addresses in their fields. Only headers with this flag can lead to message delivery. These addresses will be rewritten. These headers are used to determine the recipient address only if the `-t` command-line switch (see Section 36.7.38, -t) is used.

### 35.5.3 H_DEFAULT

The sendmail program automatically sets the H_DEFAULT flag for all headers declared in the configuration file. This flag tells sendmail to macro expand the header just before it is used. Only one of each header that is marked with this flag is allowed to exist in the headers portion of a mail message. If such a header already exists, sendmail does not add another. The H_FORCE and H_TRACE flags override this flag in that regard. This flag must never be specified in conf.c - it is set automatically by `H` configuration command (see Section 35.1, "The H Configuration Command").

### 35.5.4 H_RESENT

The H_RESENT flag tells sendmail that the header line is prefixed with the `resent-` string. Only headers that are marked with this flag can tell sendmail that this is a "forwarded" message. If no "forwarded" headers are found, sendmail strips any bogus `resent-` header lines from the message's header.

### 35.5.5 H_CHECK

If a header definition in the configuration file begins with a `?``flags``?` conditional, this flag is set for that header. It tells sendmail to insert this header only if one of its `?``flags``?` corresponds to one of the delivery agent's `F=` flags (see Section 35.4, "?flags? in Header Definitions"). This flag must never be specified in conf.c - it is set automatically when sendmail reads `H` lines with `?``flags``?` header flags.

### 35.5.6 H_ACHECK

The H_ACHECK flag marks a header that should normally be discarded unless a delivery agent's `F=` flag calls for its inclusion. It is usually set for the `Bcc:` header, which is discarded for the privacy of a blind carbon copy list, and the `Full-Name:` header, which is intended as a way for a user to add a full name (see the `$x` macro, Section 31.10.42) when there is no full name defined in the passwd(5) file. Note that H_ACHECK, when combined with bogus `?``flags``?` of a header configuration file declaration can cause appropriate headers to always be deleted or replaced (see Section 35.5.16). Also note that under V8 sendmail the H_ACHECK flag alone always causes a header to be replaced.

### 35.5.7 H_FORCE

The H_FORCE flag causes sendmail to always insert a header. It is used in the conf.c file with selected trace headers. It can be thought of as allowing duplicates. That is, the header will be inserted even if one like it is already present.

### 35.5.8 H_TRACE

Headers that are marked with the H_TRACE flag are counted in determining a mail message's "hop" count. This flag is intended for use in the conf.c file.

### 35.5.9 H_FROM

Headers that are marked with the H_FROM flag are assumed to contain a valid sender address. This flag is intended for use in the conf.c file.

### 35.5.10 H_VALID

The H_VALID flag is set and cleared internally by sendmail to indicate to itself that a particular header line has been correctly processed and can now be used as is. This flag should never be used in the conf.c file.

### 35.5.11 H_ERRSTO

The H_ERRSTO flag specifies which headers can be used for returning error notification mail. Those headers take priority over all others for that notification if the `UseErrorsTo` (`l`) option is true (see Section 34.8.74, UseErrorsTo (l)).

### 35.5.12 H_CTE

The H_CTE flag specifies that a header is the MIME RFC1521 content transfer encoding header (see Section 35.10.8, Content-Transfer-Encoding:).

### 35.5.13 H_CTYPE

The H_CTYPE flag specifies that a header is a MIME RFC1521 content-type header (see Section 35.10.9, Content-Type:).

### 35.5.14 H_BCC

The H_BCC flag indicates that a header is either a `Bcc:` (see Section 35.10.4, Bcc:) or a `Resent-Bcc:` header. The disposition of those headers is covered under the `NoRecipient-Action` option (see Section 34.8.43, NoRecipientAction).

### 35.5.15 H_ENCODABLE

The H_ENCODABLE flag tells sendmail that the field part may be encoded in the way described in RFC1522. As of V8.8, this flag is unsupported in code.

### 35.5.16 Replacing Headers with H_ACHECK

Some MUAs tend to insert their own `Message-ID:` header (see Section 35.10.19, Message-ID:). This can cause difficulty tracing email problems, because those MUA headers lack the sendmail queue identifier. One solution is possible at sites that have a central mail hub machine. At such a site, all the client machines use a simple configuration file that forwards all mail to the hub for processing.

To delete the bogus `Message-ID:`, so that a good one will be generated on the hub, you can redefine `Message-ID:` in conf.c:

>     "message-id",           0,
>     "message-id",           H_ACHECK,        change to this

Here, we changed the `0` flag for the `Message-ID:` header into a H_ACHECK flag. We do this only on the client machine versions of sendmail but not on the hub. The `Message-ID:` header will then be stripped from every outgoing message on every client machine and created (if missing) on the hub.

35.4 ?flags? in Header Definitions |  | 35.6 Headers by Category